IBIS Macromodel Task Group Meeting date: 30 March 2021 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo Rui Yang Luminous Computing David Banas Marvell Steve Parker Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Fangyi said he had a new presentation "Summary of BIRD210 Flow". - Walter noted that he had sent out a PAMn BIRD draft and another BIRD draft explaining the technique of passing a unit impulse response in as a crosstalk column to get the model to return its equalization's response. ------------- Review of ARs: - Walter to submit his BIRD211. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 23rd meeting. Curtis noted two minor corrections: 1. Justin Butterfield had taken the minutes. 2. In the second sentence of the fourth paragraph of the BIRD210 discussion, this phrase: "...additional column for the unit impulse response is not modified." should be: "...additional column for the downstream impulse response is not modified." Walter agreed. With these two changes, Walter moved to approve the minutes. Curtis seconded the motion. There were no objections. Curtis said he would send out an amended version, so the corrections should appear in the version posted to the ATM minutes archives. ------------- New Discussion: Redriver Flow Issues: Fangyi shared his new "Summary of BIRD210 Flow" presentation. - slide 2 - Current Flow This slide depicts the current IBIS 7.0 flow and introduces a block diagram style depicting the input and output IRs of the various Tx and Rx Init functions. - slide 3 - Current Flow continued... This slide lists what is shown in slide 2 for Init inputs. It also makes particular note of two things the legacy flow enabled: the Tx Init can optimize based on its downstream channel, and the Rx Init can optimize based on its upstream channel and crosstalk. - slide 4 - BIRD210 Flow This slide depicts the BIRD210 flow using the block diagram style from slide 2. The white boxes represent the legacy flow of information, which is entirely preserved in BIRD210. The blue boxes represent the two new additional columns. The empty blue boxes indicate place holder columns as inputs (the EDA tool does not put anything in these columns, and the model returns something in them). slide 5 - BIRD 210 Flow continued... The first new column provides the cumulative upstream IR as an input to all the Tx and Rx Init functions. The second new column is used by the models to return their equalization's response. The terminal Rx returns cumulative IR for the entire channel, including its own LTI and DFE effects. The terminal Rx returns the LTI portion of its equalization in the second new column. This slide notes that the Tx Init under BIRD210 can optimize based on its downstream, upstream, or both. The Rx Init can optimize based on its upstream response and crosstalk. slide 7 - Statistical Simulation with Crosstalk This slide depicts the flow of various crosstalk combinations. It notes that the BIRD210 flow provides the EDA tool with all the individual sections' through and crosstalk responses, so the EDA tool can construct all possible crosstalk paths. slide 8 - Summary This slide summarizes the benefits of BIRD210 and highlights some differences between it and BIRD211. The information in legacy columns of the impulse matrix is unchanged, and new columns are added for the new information. So legacy models, including any Tx that optimizes based on its downstream channel, still work. Rx models that optimize based on crosstalk won't have to deduce whether one of the crosstalk columns actually contains a unit IR passed in by the EDA tool for the purpose of getting the model's equalization response back. Bob said he was wrestling with the choice between BIRD210 and BIRD211. He asked if there were any technical objections to BIRD210 or any reasons why it can't work as presented. Walter offered comments on slide 4, the BIRD210 flow. He offered an example scenario in which he had a primary Tx that's a dual model and works fine, a redriver Rx that works fine and follows the white boxes (legacy portion) of Fangyi's flow chart, a redriver Tx that doesn't optimize itself and just takes the output of the redriver Rx and modifies it and sends it to the downstream channel, and finally a terminal Rx that has DFE and optimization. He said device vendors have been providing him with these types of models all along, and they just work with his BIRD211 redriver flow. With BIRD210, however, these models just don't work. All 4 models would have to be rewritten to handle the two additional columns shown in blue, but none of the extra information in blue is necessary in the most common cases when the redriver Tx does not optimize based on the downstream channel and the terminal Rx does not change its equalization based on the crosstalk input. Since all the models we currently have "on the shelf" today don't need the blue columns, why not just adopt BIRD211 and make them all work simply by changing the flow so that the output of Rx1 is included in what is passed into Rx2 instead of being added to the output of Rx2? Walter said BIRD211 works with every model that is out there. Fangyi said BIRD210 is designed to be consistent with the legacy flow and not change anything for legacy models. A legacy model wouldn't even know about the two new columns. Walter said the problem is that the legacy flow for redrivers is completely broken, and if a model doesn't have access to the new columns in the BIRD210 flow then it doesn't work at all. With BIRD210 if you have an old model the flow is broken. Ambrish again emphasized that we are only talking about the redriver "statistical flow" as having a problem the requires fixing. Fangyi said both proposals have cases they correct and cases they will break. He said Walter's BIRD211 will break if the redriver Tx optimizes based on the downstream channel, and it will also break if the Rx model optimizes based on crosstalk aggressors. Walter did not agree with these statements. Walter shared his BIRD211. He reviewed the flow diagrams in the Definition of the Issue section and noted that we all agree that the existing flow is fundamentally broken because the terminal Rx's Init function does not see everything upstream. The flow diagram for the common case in BIRD211 includes the Rx1 output in the input to Tx2, though Walter noted that this is equivalent to what BIRD166 proposed, where the output of Rx1 was combined with the output of Tx2 and passed to Rx2, for the common cases where the Tx2 does not optimize and is entirely LTI. Walter noted that the co-author of BIRD166 was an IC vendor. Walter said his BIRD only adds the new parameter for the Tx2, and only in the special case where the Tx2 optimizes based on the downstream channel. He agreed this case had not been handled by BIRD166, and said Fangyi's concern about BIRD166 had been legitimate. But with BIRD211 the Tx2 gets the upstream info it needs to optimize and avoid saturation, and with the new parameter it can also specify that it needs the downstream channel response so it can handle some effects optical channels care about. He said such optical channel models are currently being developed and not already distributed. Walter said any legacy electrical channel Tx2 model that optimizes based on the downstream channel would have to be rewritten, but he was only aware of one that ever did that, and it is now likely obsolete. Walter then addressed potential issues with crosstalk. He said that with his BIRD211 flow the Rx2 gets all the aggressing crosstalk information. He noted that if all the models are Dual models, then we would never need to know the impulse response of the equalization from Init, and we would never have to worry about deconvolution to figure it out. In terms of Init processing, the Rx2 gets all the crosstalk information it needs. If the Rx2 is doing anything with crosstalk then it needs all the upstream models to have Init_Returns_Impulse = True, because it would need all the upstream information in Init because there is no crosstalk modification in GetWave. Walter said there are two reasons an Rx model looks at crosstalk. One is crosstalk cancellation, in which case an Rx typically worries about crosstalk from adjacent signal lines and puts them through processing to cancel the crosstalk. He said this requires the EDA tool or user to tell the model which of the crosstalk columns in the impulse matrix are the ones to be cancelled. He said the potential gains from this type of processing are dramatic, but it only works for FEXT and is disaster for NEXT. Walter said the other use of crosstalk by an Rx model would be to optimize and make tradeoffs between CTLE, DFE, FFE, etc. He said anyone writing a model that sophisticated would not be doing an Init Only model. If it's doing all that sophisticated stuff, then it would have to have a GetWave anyway. Fangyi said Walter was making assumptions, and that one of the purposes of the second new column in BIRD210 was to provide the filter's response so the tool can make a proxy GetWave for an Init Only model. Walter said any model maker smart enough to write a model optimizing based on crosstalk would provide a GetWave. So, there would be no need for the EDA tool to determine the response of the filter from the Init processing, and no need to worry about confusing the model by passing in a unit IR in a crosstalk column for the purpose of determining the equalization's response. He said if we really want to make a special case for a crosstalk optimizing model maker that is too lazy to add a GetWave and doesn't make their model smart enough to ignore a unit IR passed in via a crosstalk column, then he thought we should take that up in a separate BIRD. Fangyi said his BIRD already handles such cases and makes no assumptions. Walter said that model makers won't want to be burdened by BIRD210 changes when they're only needed for very specific cases, and as an EDA vendor he did not want to deal with extra columns in cases where it's unnecessary. Walter said there are two purposes for a BIRD. One is to let EDA tools know how to run the simulations, the other is to tell model makers how to make their models. He said as long as the model maker isn't doing anything special, his standard BIRD211 flow works fine. The exception might be a legacy Tx2 that optimized based on its downstream, but the existing flow is completely broken for that case too. He said any EDA vendors are already using a flow similar to BIRD211 for their redriver simulations, or they're getting terribly wrong answers. PAMn BIRD: Walter said he'd sent out a draft of a PAMn BIRD. He said they had an internal debate about whether to write a PAM3 BIRD or a more general PAMn BIRD. He said he'd decided to do a more general BIRD, so the levels are in a table instead of introducing new PAM3_... threshold parameters. Arpad and Fangyi said they thought there were problems with addressing the different ways data could be encoded for the same PAMn. Walter asked everyone to read the BIRD draft and be ready to discuss it next time. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Curtis to send out amended minutes from the previous meeting. ------------- Next meeting: 06 April 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives